-
Notifications
You must be signed in to change notification settings - Fork 713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attempt to fix issues seemingly caused by global loading state not being observed. #11392
Attempt to fix issues seemingly caused by global loading state not being observed. #11392
Conversation
Build Artifacts
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry - I had thought this was only impacting the coach - I will revisit! |
@pcenov I replicated this issue as well and am fairly sure it should now be fixed. |
@@ -12,7 +12,12 @@ | |||
:loading="loading" | |||
:appearanceOverrides="appearanceOverrides" | |||
> | |||
<div class="coach-main"> | |||
<KCircularLoader | |||
v-if="coreLoading" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some time ago, we attempted to move away from having global loading state being managed by these root pages but instead let it be managed by the child pages as such architecture showed up not being very flexible and on some cases preventing us from updating pages in a reasonable manner. I'm concerned that by introducing this again here will lead to same issues. I didn't dig into detail into all pages at this point, but here's one example where I see potential confusion https://github.com/learningequality/kolibri/blob/release-v0.16.x/kolibri/plugins/coach/assets/src/views/plan/QuizEditDetailsPage.vue#L93-L96
I didn't review in detail yet and can think about it more. Just looking at it very high-level, I think that this type of change may easily end up having unexpected impact and seems to go against the new pattern we've tried to adopt in the whole codebase to address problems caused by this approach. For now, I wanted to ask what was the reason for introducing it in this manner and if you've already considered alternatives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it'd be lots of work to do it from child pages. On the other hand, it seems that we'd need to have a look at them anyways to cleanup conflicting or overlapping loading states so that we don't run again into issues we've been cleaning up lately after the core base refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this because when the refactor happened to remove the global loading state from CoreBase, it wasn't then re-added to each individual page in coach, which for many of the pages were reliant on the global loading state preventing their components from being shown until state has been set.
As a result, all of these components make unguarded reads from their module state - or are not set up to reactively update if the module state changes while they are displayed. This is the cause of the bug that Peter has reported here.
I agree that we should be moving in the direction you describe, but this is a bandaid to account for the incomplete refactor, and I think not doing it is far more likely to leave additional regressions undiscovered until after release.
The code you are pointing to has not changed for 4 years (long predating the refactor) so I think the chance of this change causing issues for the loading state there is minimal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely agree it's caused by incomplete refactor and no problem to keep addressing this outside of the scope of this particular PR. My only suggestion would be to have an issue explaining why this change happened and in what direction we want to move on.
The code you are pointing to has not changed for 4 years (long predating the refactor) so I think the chance of this change causing issues for the loading state there is minimal.
I would rather say that we don't know, but one thing we can do to be more sure is to test loading states thoroughly.
One last high-level question, before I look into details, why is circular loader used rather than the linear one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only PRs that I am aware of that have made changes to the loading state since the refactor are this one: #11218 and this one: #11201
Neither of which affect pages that use the CoachImmersivePage, so I think the chance of a conflict between this change and previous loading state work. Unless I've missed a PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can also raise the issue of global vs local loaders in a KDS tactical if that'd be helpful. I heard more devs "complaining" about it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with mostly doing away with global loaders (although I think having the linear loader consistently be turned on until route navigation has completed at least would be fairly easy to do globally, without having to mess around with anything in each route) - but getting rid of them completely would mean that we need to rearchitect all our pages to handle their loading states internally (which is probably best achieved by moving their loading state into setup
in the component).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although I think having the linear loader consistently be turned on until route navigation has completed at least would be fairly easy to do globally, without having to mess around with anything in each route
Yes, I see value in this. Can't think of any issues in this particular case. I assume it should be pretty brief (after we deal with issues like #11219) so in that case it may even make more sense to stay with the subtler global linear loader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "it" I meant route navigation, if we stop doing API requests there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rtibbles Now when I submit the quiz I am brought back to the Home page seeing only the spinner icon and manually refreshing the page doesn't help. I have to navigate to a different plugin and come back to the Home page to see the correct data:
2023-10-16_14-33-17.mp4
Odd, I'll take another look @pcenov. |
Use loading prop instead.
Hi @pcenov - thanks, this was again caused by some sloppy programming by me - this should now be resolved (the error was that it was always waiting about 30 seconds to stop showing the loading state!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @rtibbles - everything is working correctly now, good to go!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @rtibbles. In the light of what we discussed before, I think it's good to go. I didn't check in detail the affected sub-pages - relying on QA done. One thing I'd ask you is to only prepare a follow-up issue we talked about earlier.
Follow up filed here: #11422 |
Thank you, it's looking great |
Summary
References
Fixes #11380
Reviewer guidance
@pcenov I wasn't able to exactly replicate the errors you were seeing, but have definitely made the described flow more robust. I think the errors were occurring due to conflicting state being displayed/loaded, but I can't be sure.
Testing checklist
PR process
Reviewer checklist
yarn
andpip
)